Synchronization of parallel processes

ABSTRACT

A speculative execution capability of a processor is exposed to program control through at least one machine instruction. The at least one machine instruction may be two instructions designed to facilitate synchronization between parallel processes. According to an aspect, an instruction set architecture includes circuitry that handles a speculative execution instruction and a speculation termination instruction. The speculative execution instruction may be an instruction that takes first and second operands, causes the processor to speculatively execute additional instructions if a memory location contains a value, and causes the processor to start executing instructions from an address indicated by the second operand if a mis-speculation occurs, and the speculation termination instruction may be an instruction that causes the processor to begin retiring the additional instructions.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of and claims the benefitof priority to U.S. application Ser. No. 10/797,886, filed Mar. 9, 2004;the disclosure of the prior application is considered part of (and isincorporated by reference in) the disclosure of this application.

BACKGROUND

The present disclosure describes systems and techniques relating toprogram flow control, for example, synchronizing parallel processes.

A process is an executing software program, which may or may not shareresources with other processes. Parallel processes are two or moreprocesses that operate together in a computing system (e.g., parallelthreads of a program) and share at least one system resource that maynot be accessible by all the parallel processes together (e.g., a sharedmemory resource that may be corrupted if accessed in parallel bymultiple processes). Access to such shared resources frequently needs tobe synchronized, and this is typically done by placingshared-resource-access operations in a critical section of a program.

A critical section of a program may enforce serialized access to ashared resource among parallel processes. Traditionally this has beendone using some form of atomic operation. An atomic operation ismultiple sub-operations on a resource (e.g., read, modify and then writeto a memory location) that the processor architecture forces to beperformed together by not allowing multiple processes to overlap theirperformance of the multiple sub-operations. For example, an atomicread-modify-write instruction may be provided for use with a lockvariable for a critical section; or support for a semaphore may beprovided for use in controlling how many parallel processes can access acritical section. Thus, the processor architecture enables a simpleshared resource to be made into a protected resource (e.g., a protectedvariable), which must be shared sequentially because of the processorarchitecture itself, allowing programmers to synchronize access to anynumber, and type of shared resources.

DRAWING DESCRIPTIONS

FIG. 1 illustrates synchronization of parallel processes.

FIG. 2 illustrates synchronization of parallel processes using processorspeculation and cache coherence maintenance.

FIG. 3 is a block diagram illustrating a data processing machine.

FIG. 4 is a block diagram illustrating a system including amultiprocessor.

FIG. 5 illustrates an example code section implementing synchronization.

FIG. 6 illustrates a reorder buffer as may be used in a processor thatsupports a speculative execution instruction and a speculationtermination instruction.

Details of one or more embodiments are set forth in the accompanyingdrawings and the description below. Other features and advantages may beapparent from the description and drawings, and from the claims.

DETAILED DESCRIPTION

FIG. 1 is a flowchart illustrating synchronization of parallelprocesses. Parallel processes are generated in a data processing machineat 100. For example, a software program may be run that spawns multiplethreads in the data processing machine. The term “parallel processes”refers to the broad software design concept of parallel processingoperations with a shared resource, and is not limited to a particularhardware and operating system design. The parallel processes aremultiple threads of control, which may be parallel threads, tasks, orsystem processes with different process identifiers in a multitaskingoperating system (e.g., different Windows® processes in a Windowsoperating system).

Moreover, the parallel processes may be in a uniprocessor ormultiprocessor data processing machine. Thus, the fact that theprocesses are “parallel”, does not mean they must run simultaneously, aswould be possible in a symmetric-multiprocessing (SMP) machine, butrather that the processes are designed so that they can run concurrentlyand access a shared memory resource. The parallel processes may run inany order, and thus access to the shared memory resource should besynchronized to provide the proper processing results.

Synchronization between the parallel processes is effected usingprocessor speculation in the data processing machine at 110. The dataprocessing machine may include an out-of-order processor/processingsystem that provides speculative execution of machine instructions, andthis processor speculation capability is exposed to program control.Using processor speculation to implement synchronization among parallelprocesses may provide a significant advantage in that, if a criticalsection of a program happens to be uncontended at runtime (e.g., onlyone of the processes happens to need the critical section at a giventime), then the overhead of traditional locking may be eliminated.

Synchronization can incur a large cost in modern out-of-order pipelinedprocessors. A lock instruction is usually implemented as a serializingoperation, which makes the operation expensive. In particular, a lockinstruction may not execute speculatively, and in turn, this may impedethe speculative execution of succeeding instructions (e.g. the criticalsection). This contributes to making the lock operation expensive.Modern software languages, such as Java, provide built-in support formulti-threaded programming, and thus synchronization may be a frequentoperation in the programs written in these languages.

In contrast, using the speculative execution capabilities of modernprocessors to effect synchronization among parallel processes maysignificantly improve performance, especially in well tuned software,where a high percentage of the locks on a critical section may beuncontended at runtime. Output resulting from the synchronized parallelprocesses is provided at 120. This output may be provided to one or moreother processes in the data processing machine, or to another dataprocessing machine.

FIG. 3 is a block diagram illustrating a data processing machine 300.The machine 300 may be a uniprocessor machine or a multiprocessormachine. The machine 300 may also employ various advanced processorarchitecture features, such as super-pipelining and/or hyperthreading.

The machine 300 includes two or more parallel processes 310 operating inan applications layer and/or an operating system of the machine 300.Additionally, the machine 300 includes a processor/processing system inhardware, which may be an out-of-order processor/processing system, thatprovides speculative execution of instructions. An out-of-orderprocessor may include a memory sub-system 320 and execution units 330.The memory sub-system 320 may include a system bus, a bus interfaceunit, and a cache, which may be divided into an instruction cache and adata cache and/or into multiple levels (e.g., a level 1 cache and alevel 2 cache). The memory sub-system 320 also may include a memoryinterface unit and memory order buffer (MOB). The execution units 330may include integer, floating point, and multimedia (e.g., SingleInstruction, Multiple Data (SIMD)) execution units.

The out-of-order processor includes an in-order front end 340 thatobtains instructions, and an out-of-order execution engine 350 thatre-orders the instructions received from the in-order front end 340 andprovides speculative execution. The in-order front end may include afetch-decode unit 342, an instruction cache 344, and a branch predictionunit 346. The out-of-order execution engine 350 may include anout-of-order execution management unit 352, including at least onebuffer (e.g., a reorder buffer), and an in-order retire-store unit 354.

In general, one or more fetch-decode units may pull instructions from acache and decode these instructions before placing them in an executionmanagement back end of the processor. Decoding the instructions mayinvolve breaking up more complex instructions into smallermicro-instructions and/or translating instructions into largermacro-instructions, depending on the processor architecture. Moreover,the out-of-order execution management unit 352 may include adispatch-execute unit that checks instructions in a reorder buffer andprocesses those that have all the necessary information for execution.

The retire-store unit 354 may inspect instructions in the out-of-orderexecution management unit 352. The retire-store unit 354 may removecompleted instructions and store instruction results temporarily untilthey are sent back to a cache. The retire-store unit 354 also mayreceive completed instructions directly from a dispatch execute unitand/or the execution units 330.

The out-of-order processor/processing system of the machine 300 has aninstruction set architecture (ISA) 360 including speculative executioncontrol circuitry that handles at least one machine instruction thatfacilitates synchronization between parallel processes by exposing theprocessor speculation to program control. For example, two newinstructions, a speculative execution instruction and a speculationtermination instruction, can be added to the ISA of a processor having amechanism to execute instructions speculatively. These two newinstructions can then be used to implement synchronization.

The speculative execution (“spec”) instruction may take first and secondoperands (e.g., spec loc, addr), behave as a no-op if a memory locationindicated by the first operand contains a non-zero value, cause theprocessor to speculatively execute additional instructions if the memorylocation contains a zero value, and cause the processor to startexecuting instructions from an address indicated by the second operandif a mis-speculation occurs. The nature of a mis-speculation during thespeculative execution may depend in part on the processor architecture.

The hardware may provide invalidation based cache coherence to detectmemory dependence violation, such as may be implemented using a MOB inthe memory sub-system 320 and a snoop controller in a data cache unit. Aprocessor/processing unit may maintain a queue of load addresses andsnoop the bus to check whether any other processor/processing unitintends to write to a memory location that it has read. A memorydependency violation may be handled in the same way as a branchmis-prediction: the in-flight instructions may be flushed (e.g., anystores, or other changes caused to processor state by the in-flightinstructions are discarded), and the processor may begin fetching fromthe mis-speculation address (e.g., the second operand of the specinstruction). Other approaches to detecting a memory dependencyviolation, and to starting execution from a different address if amisspeculation occurs, are also possible.

During the speculative execution, the processor may check for dependencyviolations, such as read-after-write (RAW) dependencies, to identify amis-speculation. In a uniprocessor machine, an interrupt may beconsidered a mis-speculation, and thus, if a speculative instructioncauses an interrupt, this may shoot down the speculation. For example,the machine hardware may keep track of clock interrupts, and a contextswitch in a uniprocessor implementation may be considered amis-speculation. Moreover, multiple types of external events, such asDMA (Direct Memory Access) events, may also be treated asmis-speculation. In a multiprocessor implementation, memory dependencyviolations, interrupts, DMA events, etc. may all be treated asmis-speculation.

The speculation termination (“commit”) instruction may cause theprocessor to begin retiring the additional instructions if theadditional instructions have been speculatively executed. The commitinstruction brings the processor out of the speculation mode initiatedby the spec instruction, and while the processor is retiring thespeculative instructions, the processor continues checking for amis-speculation (e.g., an interrupt or a dependency violation) until theprocessor retires the commit instruction. If the processor detects amis-speculation, it flushes any remaining speculative instructions, andstarts executing instructions from the specified address. For example,the commit instruction may take first and second operands (e.g., commitloc, addr), behave as a no-op if a memory location indicated by thefirst operand contains a non-zero value, and cause the processor tostart executing instructions from an address indicated by the secondoperand if a mis-speculation occurs while the processor is retiring thespeculative instructions.

FIG. 5 illustrates an example code section 500 implementingsynchronization according to the new approach. By way of comparison, aconventional approach to implementing synchronization through an atomicread-modify-write of a memory location is as follows:

volatile int lock_var; .... grab_lock: if(lock_var==0){  //denotesunlocked state lock; cmpxchg lock_var,0,tid; //atomic read-modify-writeif(lock_var==tid){  //got the lock CS;  //critical section lock_var=0; //unlock } else goto grab_lock;  //try again } else goto grab_lock; //try againThe variable lock_var denotes the memory location, where Lock_var beingequal to zero implies that the lock is currently free. Everyprocess/thread in this example has a unique identifier that is given bythe identifier tid. The cmpxchg is an atomic operation that compares thecontents of the memory location with zero, and if the memory locationequals zero, the operation then modifies the location to contain tid.

The new approach may convert the atomic read-modify-write into aspeculative read-modify-write, as follows:

volatile int lock_var; // lock_var is the lock variable if(lock_var==0){// this denotes unlocked state loc=0; spec loc, shoot_down; //beginspeculation, goto shoot_down // if misspeculated rl=lock_var; //line 1if(rl==0){ //line 2 lock_var=tid; //line 3 } commit loc,shoot_down;//start retiring, goto shootdown on // violation if(lock_var==tid){ //iftrue then got the lock CS; //critical section lock_var=0; //unlock gotopost_lock; } shoot_down: //there was a conflict, do the usual // atomicoperation grab lock the conventional way ... post_lock: normal programflow ...If only one process/thread tries to grab the lock at any time, then thespeculative read-modify-write (lines 1, 2, and 3 above) may occurwithout any mis-speculation, and as a result, the read-modify-write getscommitted, and hence the process/thread gets to own the lock. However,if multiple processes/threads attempt to acquire the lock at the sametime, then this results in a mis-speculation because line 1 is a readfrom a memory location and line 3 is a write to the same memorylocation, thus causing a RAW dependence violation. The speculation isaborted, instructions from the shootdown label are fetched, and thus theprocesses/threads fall back upon the conventional method of grabbing thelock.

The syntax for the speculative execution instruction and the speculationtermination instruction in this example is merely exemplary. The ‘loc’(which denotes a memory location) in the commit syntax is used toidentify the previously executed spec instruction. The commit forms aspeculation block with the spec instruction that has the same value of‘loc’ in this example. However, another syntax is also possible. Forexample, the commit instruction may have no operands, form a block withthe previous spec instruction, and use the same shoot down addressspecified in the spec instruction.

FIG. 6 illustrates a reorder buffer 600 as may be used in a processorthat supports a speculative execution instruction and a speculationtermination instruction. The reorder buffer 600 includes a head 610 anda tail 620 of the instructions in the instruction pool. The instructionsmay be in the form of micro-ops or macro-ops.

The reorder buffer 600 may include a to-be-retired (TBR) pointer 630(pointing to the head instruction 610) and a can-be-retired (CBR)pointer 640. The TBR pointer 630 indicates which instruction is beingretired, and the CBR pointer 640 indicates which instructions havefinished executing and can be retired. The pointers 630, 640 may bededicated registers that hold indices into the reorder buffer 600. Whenthe pointers 630, 640 hit a speculative execution instruction, the TBRpointer 630 may be stopped from advancing until the CBR pointer 640 hitsa speculation termination instruction.

Thus, the processor does not start retiring the first instruction in thespeculative block until the last instruction, and all the intermediateinstructions, have been executed and are ready to retire. As shown inthe reorder buffer 600, a speculative execution instruction 610 hasstopped the TBR pointer 630, the CBR pointer 640 points to a currentinstruction 650, and a speculation termination instruction 670 has notyet been executed and cannot be executed until after an intermediateinstruction 660 has been executed. Once the CBR pointer 640 reaches thespeculation termination instruction 670, then the TBR pointer 630 isfree to advance, and the processor begins retiring instructions again.Mis-speculation checking continues while the TBR pointer 630 advancestoward the CBR pointer 640.

As the CBR pointer 640 scans the instructions in the block ofinstructions, the execution engine may identify any of the instructionsin the block that may trigger a mis-speculation, for example aninstruction that may raise an interrupt, and send a correspondingmessage to the front end of the processor. The entire speculative blockof instructions (the instructions between the head and the tail of theROB) may then be flushed from the pipeline, and a message to thein-order front-end may provide the address from where to begin fetchingthe new instructions to fill the reorder buffer 600. The circuitry usedto implement this in the processor may be similar to that used inhandling branch mis-prediction in current processors.

In a multiprocessor environment, a MOB may detect a memory violation andthen communicate this to the front-end and the reorder buffer. Thiscauses the in-flight instructions to be flushed and new instructions tobe fetched from a different location. The MOB may keep a buffer thatcontains the addresses that have been read by the instructions in thereorder buffer in a first processor (the current in-flight non-retiredinstructions). If a different processor writes into any of theseaddresses, then the different processor may send an invalidation signalto the first processor to maintain cache coherency. The snoop controllerin the first processor monitors the invalidation signals on the bus, andif the address of any of those signals matches any of the load addressesin the MOB, then the snoop controller/MOB sends a signal to the reorderbuffer and the front-end that triggers mis-speculation and theconsequent recovery.

Referring again to FIG. 5, if the acquisition of the lock isuncontended, then the entire lock-check sequence (lines 1, 2, and 3) andcritical section may be performed without having to disturb pipelinedprocessing. In particular, no dependence violations are caused, and thecritical section is executed without any locking operation beingrequired.

If multiple processes/threads attempt to grab the lock at the same time,they will execute the speculative read-modify-write sequence (line 1,line 2, and line 3). They will then execute the commit instruction andstart retiring the speculative sequence. One process/thread, T_(i), maybe the first to commit the store instruction in line 3. This means thatT_(i) will have done a successful request for ownership (RFO) for thecache line containing the variable lock_var, and invalidated copies withother processors. Because the first instruction (line 1) in thespeculative sequence is a load of the same memory location, the store byT_(i) will cause a dependency violation in all the otherprocesses/threads, and cause them to mis-speculate. Cache coherenceenforces the fundamental property that stores to the same address areserialized. Thus, for stores to the same address by multiple processors,all the processors see the stores in some particular order, and all butone processor will be shot down due to the dependence violations. Allother threads will branch to the code sequence in shoot_down and try tograb the lock by using the conventional atomic read-modify-writeoperation.

FIG. 2 illustrates synchronization of parallel processes using processorspeculation and cache coherence maintenance. Machine instructions,including a memory access instruction, are speculatively executed in aprocessing system to effect synchronization at 200. The speculativelyexecuted machine instructions are retired at 210. Cache coherence ismaintained in the processing system, during the speculative executionand the retiring of the instructions, to effect the synchronizationbetween the parallel processes at 220. Any violation of cache coherenceduring the executing-retiring interval implies that synchronization wasnot successful. Conversely, if there was no violation, it implies thatsynchronization was successful.

FIG. 4 is a block diagram illustrating a system including amultiprocessor. A data processing machine 420 is communicatively coupledwith one or more information sources 410 through a network 400. Themachine 420 may include a communication interface 430, a virtual machine440, and a memory 450. In addition, the machine 420 includes amultiprocessor 460, which includes multiple processors/processing units462. The multiprocessor 460 employs the systems and techniquesdescribed, and may include multiple processing units on a single die oron multiple chips.

The machine 420 may receive software via the network 400 and send outputto other data processing machines via the network 400. The virtualmachine 440 may translate software information indicative ofinstructions into one or more machine instructions that controlspeculative execution in the multiprocessor 460. For example, thevirtual machine 440 may be a Java virtual machine that translatesmulti-threaded Java code into machine instructions. In addition, one ormore environmental sensors 470 may be connected with the processor toprovide information regarding the environment of the machine 420, suchas in the case where the machine 420 is a remote monitoring station.

The systems and techniques described here represent a new programmingparadigm for implementing synchronization. This new programming paradigmmay offer significant processing speed advantages for multi-threadedprograms. Although only a few embodiments have been described in detailabove, other modifications are possible and readily apparent from thedescription herein.

For example, a possible implementation of the spec instruction is torestrict the window of speculation to the reorder buffer size, andtrigger a mis-speculation otherwise. If the CBR pointer reaches the TBRpointer, which implies that a commit instruction was not found insidethe ROB, then a mis-speculation is triggered. The pipeline is flushedand the processor starts fetching from the mis-speculation address.

Instead of two instructions, a single speculative instruction may beprovided that commits after a certain number of speculativeinstructions, either a fixed number of instructions or an input numberof instructions. An input number N may be in a third operand, which maycorrespond to N instructions to speculate. Other embodiments are alsopossible.

In addition, the new instructions described can be used in othercontexts as well. For example, they can be used for implementingnon-faulting loads by putting the loads after the spec instruction. Thesemantics of the spec instruction ensures that the loads are committedonly if they do not cause an interrupt/fault. Non-faulting loads can beused for software prefetching.

The logic flows depicted in FIGS. 1 and 2 do not require the particularorder shown, sequential order, or that all operations illustrated beperformed, to achieve desirable results. Other embodiments may be withinthe scope of the following claims.

1. A processor comprising: a front end that obtains instructions; and aback end that provides speculative execution of the instructions;wherein the processor includes an instruction set architecture andspeculative execution control circuitry that handles at least onemachine instruction that facilitates synchronization between parallelprocesses by exposing processor speculation of synchronization lockacquisition code to program control; wherein the processor speculationchecks for a dependency violation during acquisition of thesynchronization lock.
 2. The processor of claim 1, wherein the at leastone machine instruction of the instruction set architecture comprises aspeculative execution instruction and a speculation terminationinstruction, the speculative execution instruction causes the processorto speculatively execute additional instructions, and the speculationtermination instruction causes the processor to begin retiring theadditional instructions.
 3. The processor of claim 2, wherein the frontend comprises an in-order front end, and the back end comprises anout-of-order execution engine, which re-orders the instructions, and anexecution unit that perform the re-ordered instructions.
 4. Theprocessor of claim 3, wherein the out-of-order execution enginecomprises an out-of-order execution management unit, including at leastone buffer, and an in-order retire-store unit.
 5. The processor of claim4, wherein the at least one buffer comprises a reorder buffer.
 6. Theprocessor of claim 2, wherein the front end comprises a fetch-decodeunit and a branch prediction unit.
 7. The processor of claim 2, whereinthe processor speculation checks for an interrupt during acquisition ofthe synchronization lock.
 8. The processor of claim 2, wherein thespeculative execution instruction takes two operands, and thespeculation termination instruction takes two operands.
 9. Amachine-implemented method comprising: generating parallel processes ina data processing machine; effecting synchronization between theparallel processes using processor speculation in the data processingmachine to speculatively execute one or more instructions thatread-modify-write a lock variable associated with a critical section;and providing output resulting from the synchronized parallel processes.10. The method of claim 9, wherein said effecting synchronizationcomprises ending speculative execution of the one or more instructionsthat read-modify-write the lock variable before performing the criticalsection.
 11. The method of claim 10, wherein said effectingsynchronization comprises placing in an out-of-order executionmanagement unit of a processor, at least one machine instruction thatlimits when other machine instructions are retired from the out-of-orderexecution management unit.
 12. The method of claim 11, wherein saideffecting synchronization comprises translating at least one high-levelsoftware instruction into at least one machine instruction that controlsspeculative execution in a processor.
 13. The method of claim 12,wherein said generating parallel processes comprises running a softwareprogram that spawns multiple threads in the data processing machine. 14.The method of claim 12, wherein said providing output comprises sendingthe output to another data processing machine.
 15. An article comprisinga machine-readable storage medium embodying information indicative ofinstructions that when performed by one or more machines result inoperations comprising: generating parallel processes in a dataprocessing machine; effecting synchronization between the parallelprocesses using processor speculation in the data processing machine tospeculatively execute one or more instructions that read-modify-write alock variable associated with a critical section; and providing outputresulting from the synchronized parallel processes.
 16. The article ofclaim 15, wherein said effecting synchronization comprises endingspeculative execution of the one or more instructions thatread-modify-write the lock variable before performing the criticalsection.
 17. The article of claim 16, wherein said effectingsynchronization comprises placing in an out-of-order executionmanagement unit of a processor, at least one machine instruction thatlimits when other machine instructions are retired from the out-of-orderexecution management unit.
 18. The article of claim 17, wherein saideffecting synchronization comprises translating at least one high-levelsoftware instruction into at least one machine instruction that controlsspeculative execution in a processor.
 19. The article of claim 18,wherein said generating parallel processes comprises running a softwareprogram that spawns multiple threads in the data processing machine. 20.The article of claim 18, wherein said providing output comprises sendingthe output to another data processing machine.